Мы уже довольно много писали о нововведениях и улучшениях недавно обновленной версии платформы VMware vSphere 7 Update 1, а также средств создания отказоустойчивых кластеров VMware vSAN 7 Update 1. Между тем, наши читатели указывают нам на интересные нововведения в части функций по работе с хранилищами в апдейте платформы (Core Storage Enhancements).
Если вы хотите подробно почитать обо всех функциях хранилищ в vSphere 7 Update 1, то рекомендуем посмотреть вот этот документ - "vSphere Storage" (но там 400 страниц, имейте в виду):
Давайте посмотрим, что из нового заслуживает внимания:
1. Улучшения VMFS
Тут 2 основных момента:
Процесс создания снапшота SESparse был улучшен - теперь он меньше раздувается, а также требуется меньше места в процессе консолидации снапшотов. Также улучшилось отображение прогресса консолидации.
Уменьшилось время "замирания" файловой системы при создании или удалении снапшотов. Это произошло за счет доработки механизма взаимодействия Affinity Manager и Resource Clusters (RC).
Поддержка томов vVols для Tanzu и Cloud Native Storage (CNS).
Оптимизация миграций виртуальных машин и операций Storage vMotion для тонких дисков - это уменьшает время, необходимое на миграцию виртуальных машин между томами vVols.
Оптимизация операций по привязке томов vVols - теперь при включении нескольких виртуальных машин одновременно эти операции выполняются в пакетном режиме, что увеличивает производительность за счет меньшего числа VASA API вызовов.
Поддержка VASA для метода аутентификации CHAP на томах vVols через iSCSI.
3. Улучшения NFS
Для NAS VAAI появилась возможность установки плагинов без перезагрузки.
Раньше клонирование NVDK или LZT диска падало с ошибкой, теперь же для них все отрабатывает отлично.
4. Функция расширения pRDM со службами Microsoft WSFC
Была добавлена поддержка горячего расширения disk/LUN для режима pass-through RDM, использующегося в кластерах Windows Server Failover Clustering (WSFC).
5. Функции NVMeoF
Поддержка Oracle RAC при использовании таргетов NVMeoF
Некоторое время назад мы писали о технологии Remote Direct Memory Access (RDMA) которая позволяет не использовать CPU сервера для удаленного доступа приложения к памяти другого хоста. RDMA позволяет приложению обратиться (в режиме чтение-запись) к данным памяти другого приложения на таргете, минуя CPU и операционную систему за счет использования аппаратных возможностей, которые предоставляют сетевые карты с поддержкой этой технологии - называются они Host Channel Adaptor (HCA).
Устройства HCA могут коммуницировать с памятью приложений на сервере напрямую. Грубо говоря, если в обычном режиме (TCP) коммуникация по сети происходит так:
То при наличии на обоих хостах HCA, обмен данными будет происходить вот так:
Очевидно, что такая схема не только снижает нагрузку на CPU систем, но и существенно уменьшает задержки (latency) ввиду обхода некоторых компонентов, для прохождения которых данными требуется время.
Поддержка RDMA появилась еще в VMware vSphere 6.5, когда для сетевых адаптеров PCIe с поддержкой этой технологии появилась возможность обмениваться данными памяти для виртуальных машин напрямую через RDMA API. Эта возможность получила название Paravirtual RDMA (PVRDMA).
Работает она только в окружениях, где есть хосты ESXi с сетевыми картами с соответствующей поддержкой, а также где виртуальные машины подключены к распределенному коммутатору vSphere Distributed Switch (VDS). Метод коммуникации между виртуальными машинами в таком случае выбирается по следующему сценарию:
Если две машины общаются между собой на одном ESXi, то используется техника memory copy для PVRDMA, что не требует наличия HCA-карточки на хосте, но сама коммуникация между ВМ идет напрямую.
Если машины находятся на хостах с HCA-адаптерами, которые подключены как аплинки к VDS, то коммуникация идет через PVRDMA-канал, минуя обработку на CPU хостов, что существенно повышает быстродействие.
Если в коммуникации есть хоть одна ВМ на хосте, где поддержки RDMA на уровне HCA нет, то коммуникация идет через стандартный TCP-туннель.
Начиная с VMware vSphere 7 Update 1, для PVRDMA была добавлена поддержка оконечных устройств с поддержкой RDMA (Native Endpoints), в частности хранилищ. Это позволяет передать хранилищу основной поток управляющих команд и команд доступа к данным от виртуальных машин напрямую, минуя процессоры серверов и ядро операционной системы. К сожалению для таких коммуникаций пока не поддерживается vMotion, но работа в этом направлении идет.
Чтобы у вас работала технология PVRDMA для Native Endpoints:
ESXi должен поддерживать пространство имен PVRDMA. Это значит, что аппаратная платформа должна гарантировать, что физический сетевой ресурс для виртуальной машины может быть выделен с тем же публичным идентификатором, что и был для нее на другом хосте (например, она поменяла размещение за счет vMotion или холодной миграции). Для этого обработка идентификаторов происходит на сетевых карточках, чтобы не было конфликтов в сети.
Гостевая ОС должна поддерживать RDMA namespaces
на уровне ядра (Linux kernel 5.5 и более поздние).
Виртуальная машина должна иметь версию VM Hardware 18
или более позднюю.
За счет PVRDMA для Native Endpoints виртуальные машины могут быстрее налаживать коммуникацию с хранилищами и снижать задержки в сети, что положительно сказывается на производительности как отдельных приложений и виртуальных машин, так и на работе виртуального датацентра в целом.
На сайте проекта VMware Labs появилась очередная полезная штука - Storage Performance Tester. С помощью данного средства администраторы VMware vSphere могут в один клик проверить производительность хранилищ в плане IOPS, Latency и циклов CPU на одну операцию ввода-вывода для серверов VMware ESXi.
Эта утилита автоматизирует все шаги, которые необходимо предпринять для тестирования, включая развертывание виртуальных машин, запуск нагрузки по вводу-выводу, а также анализ производительности хранилища. Метрики, полученные в результате тестирования, визуализируются на графиках. Единственная вещь, которую вам нужно сделать - это выполнить соответствующую команду и ждать сгенерированного отчета о производительности хоста ESXi.
Средство создано как для администраторов платформы vSphere, так и для разработчиков, которым требуется решать проблемы производительности в виртуальной инфраструктуре. Также Storage Performance Tester удобно использовать для получения максимальных параметров производительности аппаратного обеспечения, а также программных компонентов (драйверы, настройки vSphere и vSAN).
Для запуска тестовой среды вам понадобятся:
python3
sshpass
2 ГБ свободного места
Linux-окружения (с версией ядра не менее 2.6.31)
Вот небольшое обзорное видео, где можно посмотреть всю процедуру запуска утилиты и, собственно, сам отчет с результатами тестирования:
Скачать Storage Performance Tester можно по этой ссылке.
Не так давно мы писали о том, что в последней версии VMware vSphere 7 Update 1 технология vMotion стала еще быстрее и теперь обеспечивает нужды горячей миграции даже для самых тяжелых виртуальных машин.
Напомним, что VMware полностью переписала технологию vMotion memory pre-copy с использованием нового механизма page-tracing, который существенно уменьшает время "заморозки" и переключения копии виртуальной машины на ее копию на другом хосте ESXi.
Интересны некоторые моменты. Например, в vSphere 6.7 используется технология отслеживания изменений CPU во время миграции stop-based trace, которая "подмораживает" все CPU, а в vSphere 7 U1 уже подмораживается только один процессор (техника loose page-trace Install):
Также vSphere 7.0 U1 передает compacted bitmap памяти вместо полного, что уменьшает время переключения на ВМ другого хоста:
Интересно уменьшение влияния миграции тяжелой БД Oracle на производительность - улучшение составило 19 раз!
Время миграции - до 50% меньше:
Ну и вообще в документе очень много всего интересного для интересующихся. Читайте здесь.
На сайте проекта VMware Labs вышла очередная новая утилита - vSphere Pod Autoscaler, предназначенная для пользователей vSphere PodVM, которые хотят настроить автомасштабирование узлов PodVMs на базе использования ими памяти.
Суть ее заключается в том, что при удалении снапшота ВМ, по завершении ее резервного копирования, она замирает примерно на 30 секунд, не принимая никакой ввод-вывод. Происходит это на некоторых NFS-хранилищах, в частности HPE SimpliVity. В итоге - приложения, чувствительные ко времени, работают плохо, ну и в целом такое поведение не очень приятно для производственных систем.
Проблема проявилась при использовании платформы VMware vSphere 6.7, текущей версии Veeam Backup and Replication и хранилища HPE SimpliVity, которое поддерживает презентацию томов только в режиме NFS v3.
При этом в такой же комбинации продуктов, но на блочных хранилищах удаление снапшота занимало 1-2 секунды.
После общения с поддержкой нашлись следующие workaround'ы, которые не подошли:
Использовать NFS v4 вместо v3 (доступно не на всех хранилищах)
Использовать другой транспорт (transport mode), например, Direct access или NBD (Network Block Device). Но Direct access доступен не всегда, а NBD - медленный режим.
Можно использовать режим hot-add с виртуальным модулем backup appliance, но тогда он должен быть на каждом хосте (см. KB 201095).
Можно отключить синхронизацию времени с хостом для ВМ с приложениями, которые страдают из-за замирания времени в гостевой ОС. Об этом можно почитать в KB 1189. Но это так себе решение.
На текущий момент получается, что это проблема именно VMware ESXi, см. статью KB 2010953. Также она описана и в базе знаний Veeam - KB 1681 (там же указаны и обходные пути). Таким образом, выходит, что в некоторых случаях ни одно из решений не подходит на 100%.
Недавно компания VMware объявила о доступности для загрузки новой версии фреймворка для управления виртуальной инфраструктурой с помощью сценариев PowerCLI 12.1. Напомним, что о прошлой мажорной версии PowerCLI 12, вышедшей в апреле этого года, мы писали вот тут.
Давайте посмотрим, что нового появилось в PowerCLI 12.1:
Несколько новых командлетов было добавлено в модуль VMware.VimAutomation.WorkloadManagement
Get-WMCluster
Set-WMCluster
Enable-WMCluster
Disable-WMCluster
Несколько новых командлетов для vSphere Lifecycle Manager (vLCM) было добавлено в модуль VMware.VimAutomation.Core (подробнее тут)
Get-LcmImage
Test-LcmClusterCompliance
Test-LcmClusterHealth
Вот пример работы Get-LcmImage:
В модуле VMware.VimAutomation.Core было сделано несколько улучшений, включая новые параметры для командлетов New-Cluster и Set-Cluster, а также New-ContentLibraryItem и Set-ContentLibraryItem. Также были несколько обновлены параметры командлетов New-VM/Set-VM, New-Datastore, New-HardDisk и Get-NetworkAdapter/Get-VirtualNetwork
Несколько новых командлетов было добавлено в модуль VMware.VimAutomation.Vmc:
Добавлен параметр Cluster в командлеты Add-VmcSddcHost и Remove-VmcSddcHost
Свойства VCenterHostName и VCenterCredentials добавлены объекту SDDC
В модуле VMware.VimAutomation.Storage появилось несколько новых командлетов для управления безопасной очисткой дисков vSAN, томами Cloud Native Storage и контейнерами VVols:
Start-VsanWipeVsanDisk
Get-VsanWipeDiskState
Stop-VsanWipeVsanDisk
Get/New/Set/Remove-CnsVolume
New-CnsContainerCluster
New-CnsKubernetesEntityReference
New-CnsKubernetesEntityMetadata
New-CnsVolumeMetadata
Add-CnsAttachment
Remove-CnsAttachment
Get-VvolStorageContainer
Улучшения модуля VMware.VimAutomation.Storage:
Командлеты Set-VsanClusterConfiguration и Get-VsanClusterConfiguration теперь поддерживают режимы "vSAN compression only mode" и "vSAN enforce capacity reservation"
Get-VsanSpaceUsage более гранулярно показывает статистику свободного пространства
Командлеты Get-VasaStorageArray и Get-VasaProvider теперь могут фильтровать VASA providers по контейнерам VVols
Моуль VMware.VimAutomation.Security был существенно обновлен:
Добавлен командлет Get-TrustedClusterAppliedStatus для получения примененного статуса доверенных сервисов в доверенных кластерах
Добавлен командлет Set-TrustedCluster для ремедиации кластера в состоянии "not healthy"
Несмотря на замудреное название, утилита Sample Data Platform предназначена для простой вещи - дать пользователям VMware Cloud Foundation 4.0 возможность получить платформу оперирования данными для гостевого кластера Tanzu Kubernetes Grid менее, чем за 20 минут, на примере сервисов Kafka, Spark, Solr и ELK.
Также в состав утилиты входит пример финансового приложения (с использованием реальных данных dxFeed), которое показывает, как все компоненты этого решения работают вместе.
С помощью утилиты можно выполнить 4 шага по созданию Data Platform:
Развертывание компонентов платформы Kafka, Spark, Solr и ELK за 20 минут.
Kafka Publisher - получение данных финансового рынка из публичного источника dxfeed.
Spark Subscriber - подписаться на данные рынка из топиков Kafka, обработка данных и их запись в Solr
Logstash Subscriber - подписаться на данные рынка из топиков Kafka и запись их в Elasticsearch через logstash, а также создание дэшборда kibana.
Более подробно о том, как выполняются все эти шаги можно посмотреть в видео ниже:
Скачать Sample Data Platform on VMware Cloud Foundation with VMware Tanzu for Kubernetes Provisioning можно по этой ссылке.
На прошлой неделе компания VMware выпустила новую версию своего основного руководства по обеспечению информационной безопасности виртуальной инфраструктуры VMware vSphere Security Configuration Guide 7 (SCG 7). Теперь документ содержит 78 настроек, так или иначе влияющих на безопасность как самой платформы виртуализации, так и виртуальных машин.
Что нового появилось в руководстве:
Совместимость с гайдлайнами по безопасности NIST 800-53, NIST 800-171, CMMC, PCI DSS, ISO 27001, NERC CIP
Учет аппаратных уязвимостей CPU, таких как Meltdown и Spectre
Покрытие конфигурациями новых технологий и функциональности платформы vSphere 7
Напомним, что этот документ доносит концепцию "Secure by design", что означает, что среда VMware vSphere изначально настроена оптимальным образом с точки зрения безопасности, поэтому вносить изменения вам нужно только в случае наличия каких-либо специальных требований в вашей инфраструктуре.
В документе, помимо описания рекомендуемой настройки и лога изменений, есть следующие полезные колонки:
Hardening - указывает на то, что это действительно настройка, которой нужно уделить внимание при конфигурации.
Site Specific Setting - говорит о том, что задать конфигурацию должен сам пользователь, в зависимости от его окружения.
Audit Setting - указывает, что вам необходимо время от времени проверять эту настройку, чтобы убедиться, что значение по умолчанию не было изменено администратором необоснованно.
Desired value - рекомендуемое значение, оно же и является значением по умолчанию, если это не site specific.
PowerCLI Command Remediation Example - команда PowerCLI по применению настройки.
PowerCLI Command Assessment - команда PowerCLI, с помощью которой можно узнать текущее значение настройки.
Помимо основного Excel-файла с настройками, в составе скачиваемого архива есть и руководство по применению настроек и работе с ними:
Скачать VMware vSphere Security Configuration Guide 7 одним архивом можно по этой ссылке. Конечно же, документ стоит посмотреть всем специалистам по ИБ, в компетенцию которых входит работа с безопасностью виртуальной инфраструктуры.
Как вы все знаете, на прошлой неделе прошла главная конференция по виртуализации этого странного года - VMworld 2020 Online. Несмотря на то, что она прошла онлайн, было сделано немало интересных объявлений, а перед самой конференцией были анонсированы главные обновления продуктовой линейки. Одним из них был скорый выпуск новой версии платформы VMware vSphere 7 Update 1, который и состоялся:
На днях также появилась возможность скачать новые версии нескольких продуктов, помимо vSphere 7 U1. Давайте посмотрим, какие именно решения были выпущены:
Продолжаем рассказывать об анонсах прошедшей на прошлой неделе конференции VMworld 2020 Online. В прошлый раз мы рассказывали о проекте Project Monterey, который является продолжением развития технологии Project Pacific для контейнеров на базе виртуальной инфраструктуры, а сегодня расскажем о новой сертификации.
Программа VMware Certified Technical Associate (VCTA) предназначена для тех специалистов, которые осуществляют ежедневные операции в виртуальной инфраструктуре. Обучающий курс в рамках данной сертификации затрагивает операции в нескольких облачных окружениях, настройку сети, безопасность и управление устройствами.
Если сравнивать сертификацию VCTA и VMware Certified Professional (VCP), то можно сказать, что первая - это, в основном, для начинающих администраторов, которые только погружаются в тему и отвечают за Day-2 операции, а VCP предполагает понимание всех аспектов виртуальной инфраструктуры, включая ее проектирование, развертывание и настройку.
При этом VCTA не является каким-то обязательным условием сертификации VCP, ее может получить любой желающий. Обучение происходит на портале VMware Customer Connect Learning. Основные треки сертификации VCTA:
VCTA-DCV – доступно сейчас
VCTA-NV – доступно сейчас
VCTA-SEC – доступно сейчас
VCTA-CMA – скоро будет доступно
VCTA-DW – в разработке
VCTA-AM – в разработке
Экзамены можно сдавать в тестовых центрах Pearson или дома через платформу Pearson OnVue, где ведется живой онлайн-мониторинг сдаваемых онлайн экзаменов.
На данный момент о сертификации VCTA есть документ с вопросами и ответами, который дает основные пояснения к программе. Также 27 октября пройдет онлайн-вебинар (регистрация тут), где будут озвучены основные детали новой сертификации.
Какое-то время назад мы писали о новых возможностях недавно вышедшего обновления платформы виртуализации VMware vSphere 7 Update 1. Одним из главных улучшений стало увеличение максимальных параметров платформы, что привело к возможности организовывать кластер HA/DRS из еще большего числа хостов, а на самих хостах - исполнять виртуальные машины еще большего размера.
Данные нововведения можно проиллюстрировать следующей таблицей:
В кластере теперь может быть до 96 хостов, правда не все технологии поддерживают это число. Например, кластер VMware vSAN 7 Update 1 и топология HCI Mesh поддерживают все еще 64 хоста, а технология Native File Services в vSAN 7 U1 поддерживает только 32 хоста.
Самое большое улучшение - теперь в кластере может быть до 10 тысяч виртуальных машин, а это на 50% выше показателя vSphere седьмой версии:
Для виртуальных машин, находящихся под экстремальной нагрузкой, теперь поддерживается 768 виртуальных процессоров (vCPU) и до 24 ТБ памяти. Это больше, чем для виртуальных машин на любой из других облачных или онпремизных платформ:
К подобным нагрузкам можно отнести системы на базе SAP HANA и EPIC Cache Operational Database. Все эти ресурсы виртуальная машина может реально использовать:
Для виртуальной инфраструктуры в целом на базе одного кластера в Sphere 7 Update 1 максимальные показатели следующие: 393 216 vCPU (96 хостов по 4 096 vCPU) / 2.3 ПБ памяти (96 хостов по 24 ТБ):
Если говорить об исполнении контейнеров vSphere with Tanzu в такой инфраструктуре, то их может поместиться просто огромное количество. Согласно статистике, средний размер контейнера составляет 1 vCPU и 400 МБ памяти (например, контейнер node.js "кушает" 1/3 CPU и 384 МБ памяти). Таких контейнеров в одном кластере vSphere 7 U1 может быть запущено 393 216 штук. А контейнеров node.js можно запустить до миллиона экземпляров!
Многие из вас знают, что компания VMware с каждым новым релизом мажорной версии платформы vSphere улучшает техники горячей миграции виртуальных машин vMotion. Последнее обновление VMware vSphere 7 Update 1 - не исключение, там было сделано много для того, чтобы технология vMotion работала еще быстрее и обеспечивала нужды горячей миграции даже для самых тяжелых виртуальных машин.
Ранее vMotion могла не пройти для больших ВМ, которые имели более 64 vCPU и 512 ГБ памяти (они же Monster VMs). В документе "vMotion Innovations in vSphere 7.0 U1" можно найти конкретное описание улучшений. Давайте посмотрим на них вкратце.
Прежде всего, VMware полностью переписала технологию vMotion memory pre-copy с использованием нового механизма page-tracing, который существенно уменьшает время "заморозки" и переключения копии виртуальной машины на ее копию на другом хосте ESXi.
В документе выше для примера делается миграция vMotion сервера БД Oracle, запущенного в виртуальной машине с 72-vCPU / 1 TБ памяти на борту. На картинке ниже показано число тразакций в секунду с шагом как раз в секунду - до, во время и после vMotion (тест HammerDB):
Основные выводы теста, проведенного для такой нагрузки:
Общее время миграции уменьшилось более чем в 2 раза (с 271 секунды до 120 секунд)
Итоговое время для установления трассировки уменьшилось с 86 секунд до 7.5 секунд (снизилось в 11 раз)
Общее проседание пропускной способности во время миграции - на 50% для vSphere 6.7 и всего лишь 5% для vSphere 7.0 Update 1
Ответ Oracle во время переключения в среднем стал менее одной секунды, а ранее составлял более 6 секунд
Второй тест проводили для миграции vMotion сервера БД Oracle в виртуальной машине с 12 vCPU / 64 ГБ памяти для vSphere 6.7 и vSphere 7.0 U1. На картинке ниже показано число транзакций в секунду с шагом в полсекунды - до, во время и после vMotion (тест HammerDB):
Основные результаты теста:
Общее время горячей миграции сократилось с 23 секунд в vSphere 6.7 до 11 секунд в vSphere 7.0 U1 (уменьшение в 2 раза)
Итоговое время для установления трассировки уменьшилось с 2.8 секунд до 0.4 секунд (снизилось в 7 раз)
Увеличение полосы пропускания где-то на 45% (около 3480 транзакций в секунду, по сравнению с 2403 транзакции в секунду)
Как многие из вас знают, в последние пару лет очень сильно увеличилось число и масштаб атак, связанных с уязвимостями в аппаратном обеспечении. Наибольшую известность получили уязвимости Meltdown и Spectre, которые были обнаружены в процессорах Intel.
Самый неприятный момент, связанный с подобного рода уязвимостями - это то, что поскольку они связаны с аппаратной частью процессоров на самом низком уровне, то, во-первых, ее сложнее исправить и доставить конечным пользователям, а, во-вторых, неправильное обновление, закрывающее эти дырки, может вызвать различные побочные эффекты.
Так, например, было с производительностью серверов VMware ESXi, когда производители ОС совместно с Intel выпустили соответствующие обновления, а VMware выпустила закрывающий уязвимость патч. Сам патч тогда пришлось отозвать и ждать нового, а ведь это потраченного время администраторов, время пользователей и время, в течение которого существует угроза безопасности инфраструктуры предприятия.
Поэтому производители процессоров, совместно с вендорами платформ виртуализации, сейчас уделяют этому моменту особое внимание. Конечно же, в этом направлении работает и AMD, которая активно внедряет следующие технологии:
Secure Encrypted Virtualization (SEV) - первая версия технологии, анонсированная в 2016 году. Она позволяет изолировать виртуальные машины от гипервизора, со стороны которого может быть угроза безопасности при его компрометации. Если гипервизор попытается считать память гостевой ОС, он увидит только зашифрованные данные.
SEV-ES (Encrypted State) - вторая версия технологии, представленная в 2017 году. Она дополняет защиту памяти гостевой ОС шифрованием регистров CPU гостевой ОС. Таким образом, гипервизор не может видеть регистры процессора, активно используемые виртуальной машиной.
SEV-SNP (Secure Nested Paging) - следующее поколение технологии, которое было анонсировано в этом году. Оно добавляет функции аппаратной безопасности для контроля над интеграцией памяти гостевых ОС, что защищает от таких атак, как data replay, memory re-mapping и других (подробнее тут и на картинке ниже).
В недавнем обновлении платформы виртуализации VMware vSphere 7 Update 1 появилась поддержка технологии SEV-ES (Encrypted State), которая должна еще больше защитить от потенциальных уязвимостей, связанных с доступом к данным в рамках процессора. Работает это на процессорах AMD EPYX 7xx2 CPU
или более поздних и требует VM Virtual Hardware версии 18, которое появилось в Update 1.
Надо начать с того, что у VMware уже есть защита памяти и данных гостевой ОС на уровне платформы (а в самих ОС тоже есть средства защиты памяти и процессора), но, само собой, эти механизмы на надежны на 100%, потому что ключевой компонент платформы - гипервизор, обладает очень широкими полномочиями (в виду необходимости), и при его компрометации ничего особо не поможет. Поэтому самое разумное - это поддержать подход изоляции ВМ от гипервизора на аппаратном уровне. Он, кстати, называется Trusted Execution Environment (TEE).
Подход AMD заключается в том, что они добавляют специальный Secure Processor, маленький сопроцессор, интегрированный в основной чип CPU, который является основой безопасности и поддерживает операции шифрования, в том числе и для SEV-ES.
Первое поколение EPYC CPU поддерживало хранение только 15 ключей шифрования, но следующее поколение уже поддерживает более 500. Один из таких ключей используется для гипервизора, а остальные - для гостевых систем.
Для чего вообще нужно защищать регистры процессора гостевых систем? Очень просто - когда виртуальная машина переключает контекст исполнения (меняет процессор), гипервизор получает ресурсы CPU обратно, вместе с содержимым регистров. А в них может храниться много "полезного" для злоумышленника - например, ключи для расшифровки дисков гостевой системы.
Работает механизм ключей так - гостевая ОС запрашивает у процессора с поддержкой SEV ключ шифрования для памяти, а SEV-ES расширяет его и на регистры процессора тоже, после чего гостевая ОС может безопасно использовать память и регистры, не беспокоясь что гипервизор или другие ВМ, изолированные в рамках процессов VMX, считают их содержимое. Очевидно, что гостевая ОС тоже должна поддерживать реализацию SEV-ES (поэтому надо читать соответствующую документацию к ним, чтобы узнать о поддержке).
Самым большим минусом использования технологии SEV-ES является невозможность поддержки таких техник, как vMotion, Memory Snapshots, Guest Integrity, Hot Add, Suspend & Resume, Fault Tolerance и горячих клонов - ведь для их реализации гипервизор должен иметь прямой доступ к памяти гостевых систем. В то же время надо отметить, что это не ограничение от AMD, которая заявляет, что SEV поддерживает live migration и прочее, а ограничение реализации от VMware.
В большинстве производственных окружений невозможность применения этих технологий будет ограничивать использование SEV-ES только системами, требующих наивысшего уровня защищенности.
С другой стороны, например, недавно вышедшее решение vSphere with Tanzu не использует vMotion для машин с контейнерами виртуализованных приложений - они просто выключаются на одном хосте и включаются на другом, то есть здесь есть перспективы применения SEV-ES.
Также использованием технологии SEV-ES можно управлять в пакетном режиме сразу для нескольких тысяч виртуальных машин через интерфейс PowerCLI, что особенно актуально для контейнеров Tanzu. На данный момент VMware еще не опубликовала официальный референс по командлетам для SEV-ES, ждем.
Ну и недавно VMware выпустила интересное видео, рассказывающее о первой имплементации технологии SEV-ES в платформе VMware vSphere 7 Update 1:
Как итог можно отметить, что пока такие технологии, как Secure Encrypted Virtualization имеют достаточно узкое применение ввиду их ограничений. Однако это лишь первые шаги, которые производители процессоров делают совместно с вендорами платформ виртуализации, чтобы защитить ИТ-среду предприятия он новой волны атак на программно-аппаратную инфраструктуру датацентра. Дальше все это будет развиваться, будет и поддержка AMD SEV-SNP, что уже будет существенно уменьшать поверхность возможных атак.
На этой неделе компания VMware опубликовала новость об окончании поддержки браузера Internet Explorer 11. Шаг этот совершенно логичен, поскольку сама Microsoft анонсировала окончание поддержки Explorer 11 продуктами линейки MS365 (вот официальный guidance). Пользователям предлагается мигрировать на браузер Edge.
Поддержка IE 11 будет прекращена всеми активными версиями vSphere Client, начиная со следующего за vSphere 7.0 Update 1 релиза платформы. На самом деле, де-факто IE 11 был в опале уже довольно давно, и его использует менее 2% пользователей согласно статистике (большинство, конечно же, корпоративные). Одна из причин, помимо качества предоставляемого сервиса (стабильность и производительность) - недостаточная защищенность (смотрим пример от января этого года).
Также IE не поддерживает новые возможности HTML5, не имеет полной поддержки CSS, WebAPI и WebGL. Работает vSphere Client в IE намного хуже, чем в других современных браузерах. Также там возникает много ошибок, работая с которыми VMware тратит много ресурсов.
Таким образом, скоро IE 11 вылетит из списка совместимых браузеров для vSphere Client. Случится это для всех версий с выходом vSphere 7 Update 2. В общем, имейте в виду.
Одной из новых возможностей VMware vSphere 7 U1 стала служба vSphere Clustering Service (vCLS), которая позволяет организовать мониторинг доступности хостов кластера vSphere, без необходимости зависеть от служб vCenter.
Как вы знаете, кластер HA/DRS очень зависит от постоянной доступности сервисов vCenter, который является критическим звеном виртуальной инфраструктуры. Поэтому для него организовывают такие сервисы, как vCenter Server High Availability (VCHA), но и они не идеальны. Также проблема наблюдается при масштабировании кластеров в больших окружениях, которые объединяют онпремизные и облачные площадки, где масштабируемость vCenter является серьезной проблемой.
Учитывая это, VMware придумала такую штуку - сажать на хосты кластера 3 служебных агентских виртуальных машины, составляющих vCLS Control Plane, которые отвечают за доступность кластера в целом:
Таких виртуальных машин три в кластере, где 3 или более хостов, и две, если в кластере два хоста ESXi. Три машины нужны, чтобы обеспечивать кворум (2 против 1) в случае принятия решения о разделении кластера.
Три этих виртуальных машин следят друг за другом и оповещают об этом кластерные службы vCenter:
Это самокорректирующийся механизм, что значит, что если одна из агентских машин становится недоступной или выключенной, то службы vCLS пытаются самостоятельно наладить работу ВМ или включить ее.
Есть 3 состояния служб vCLS:
Healthy – как минимум 1 агентская ВМ работает в кластере, чтобы обеспечить доступность кластера развертываются 3 ВМ для кворума.
Degraded – как минимум одна агентская машина недоступна, но DRS продолжает функционировать и исполнять свою логику. Такое может, например, произойти при передеплое служебных машин vCLS или после какого-то события, повлиявшего на их "включенность".
Unhealthy – логика DRS не выполняется (балансировка или размещение ВМ), так как vCLS control-plane недоступна (то есть ни одной агентской ВМ не работает).
Легковесные машины-агенты исполняются на хостах ESXi и лежат на общих хранилищах, если общие хранилища недоступны - то на локальных дисках. Если вы развернули общие хранилища после того, как собрали кластер DRS/HA (например, развернули vSAN), то рекомендуется перенести агентские ВМ с локальных хранилищ на общие.
Сама гостевая ОС агентских ВМ очень легковесная, используется Photon OS следующей конфигурации:
Диск в 2 ГБ - это тонкий диск, растущий по мере наполнения данными (thin provisioned). Эти машины не имеют своего нетворка, а также не видны в представлении Hosts and Clusters в клиенте vSphere.
Агентские ВМ можно увидеть в представлении VMs and Templates где есть папка vCLS:
Обратите внимание, написано, что для агентских ВМ управление питанием производится со стороны служб vCLS. Если вы попытаетесь выключить эти ВМ, то будет показано следующее предупреждение:
При переводе кластера в режим обслуживания vCLS сам заботится о миграции агентских ВМ с обслуживаемых серверов и возвращении их обратно. Для пользователя это происходит прозрачно. И, конечно же, лучше не выключать эти ВМ вручную и не переименовывать папки с ними.
Жизненный цикл агентских ВМ обслуживается со стороны vSphere ESX Agent Manager (EAM).
EAM отвечает за развертывание и включение агентских ВМ, а также их пересоздание, если с ними что-то произошло. В анимации ниже показано, как EAM восстанавливает ВМ, если пользователь выключил и/или удалил ее:
Важный момент для разработчиков сценариев PowerCLI - это необходимость обрабатывать такие ВМ, чтобы случайно не удалить их. Например, ваш скрипт ищет неиспользуемые и забытые ВМ, а также изолированные - он может по ошибке принять машины vCLS за таковые и удалить, поэтому их надо исключать в самом сценарии.
В интерфейсе vSphere Client список агентских ВМ можно вывести в разделе "Administration > vCenter Server Extensions > vSphere ESX Agent Manager".
У агентских ВМ есть свойства, по которым разработчик может понять, что это они. В частности:
ManagedByInfo
extensionKey == "com.vmware.vim.eam"
type == "cluster-agent"
ExtraConfig keys
"eam.agent.ovfPackageUrl"
"eam.agent.agencyMoId"
"eam.agent.agentMoId"
Основное свойство, по которому можно идентифицировать агентскую ВМ, это HDCS.agent, установленное в значение "true". В Managed Object Browser (MOB) выглядит это так:
Ну и напоследок - небольшое демо технологии vSphere Clustering Service:
Основной фишкой первого пакета обновления седьмой версии vSphere стал, конечно же, финальный выпуск платформы VMware vSphere with VMware Tanzu, объединяющей миры виртуальных машин и контейнеризованных приложений в рамках инфраструктуры предприятия.
Вот небольшой обзор платформы VMware vSphere with Tanzu, о первых объявлениях компонентов которой мы уже писали тут и тут (а о текущей версии рассказано в блоге VMware):
Нововведения vSphere 7 U1 разбиты на 3 блока:
Инфраструктура для разработчиков (контейнеры)
Продолжение масштабирования возможностей платформы
Упрощение операций администраторов
Итак, давайте посмотрим, что нового в VMware vSphere 7 Update 1:
1. Инфраструктура для разработчиков
Здесь VMware добавила следующие важные возможности:
Служба Tanzu Kubernetes Grid (TKG) - о ней мы упоминали вот тут. Она позволяет администраторам развертывать Kubernetes-окружения и управлять их составляющими с помощью решения для кластеров Tanzu Kubernetes. Делается это теперь за минуты вместо часов. Также TKG идет в соответствии с политиками upstream Kubernetes, что позволяет сделать процесс миграции максимально бесшовным.
Bring Your Own Networking - пользователи могут выбирать, какой сетевой стек использовать для кластеров Tanzu Kubernetes. Можно использовать традиционную инфраструктуру на базе vSphere Distributed Switch (vDS) для конфигурации, мониторинга и администрирования виртуальных машин и кластеров Kubernetes. Новый Networking for Tanzu Kubernetes clusters позволяет использовать и решения VMware NSX. Также можно использовать Antrea для максимальной производительности внутренней сети для сервисов Tanzu Kubernetes Grid.
Bring Your Own Load Balancer - можно выбирать тип балансировки L4 для кластеров Tanzu Kubernetes. Первым партнером VMware стало решение HAProxy в формате виртуального модуля OVA.
Application-focused management - теперь пользователи могут применять vCenter не только для управления виртуальными машинами, но и для обслуживания, мониторинга и траблшутинга инфраструктуры контейнеров, включая приложения и неймспейсы (подход application focused management).
2. Продолжение масштабирования возможностей платформы
В этой категории нужно отметить следующие возможности:
Monster VMs - для пользователей решений SAP HANA, Epic Operational Databases, InterSystems Cache и IRIS компания VMware позволяет масштабировать виртуальные машин до 24 ТБ памяти и до 768 виртуальных процессоров (vCPU). То есть все ресурсы хоста могут быть предоставлены виртуальной машине, требующей их большое количество. Это было сделано за счет улучшения планировщика ESXi, а также логики ко-шедулинга для больших ВМ.
Cluster scale enhancements - теперь в vSphere 7 U1 кластер может содержать до 96 хостов! Это на 50% больше значения в релизе vSphere 7 (64 штуки):
3. Упрощение операций администраторов
vSphere Lifecycle Manager - теперь vLCM поддерживает и хосты vSAN, и конфигурацию сетевого стека NSX-T. В vSphere 7 Update 1 решение vLCM также мониторит соответствие образов непрерывно, что позволяет вовремя запустить процесс обновления (remediation).
vSphere Ideas - эта функциональность позволяет пользователям запросить возможности vSphere следующих версий прямо из интерфейса vSphere Client, отслеживать статус своих запросов, видеть запросы других пользователей и голосовать за них. Не факт, конечно, что к вам прислушаются, но общую обстановку по тому, что хотят администраторы, вы будете видеть.
vCenter Connect - теперь пользователи могут управлять своими виртуальными ресурсами VMware Cloud on AWS или в других облаках на базе vCenter из единого интерфейса.
Доступность для загрузки VMware vSphere 7 Update 1 ожидается в рамках или после конференции VMworld Online 2020. Следите за нашими обновлениями!
Компания Veeam Software, широко известная своим главным в отрасли решением Veeam Backup and Replication для резервного копирования виртуальных и физических сред, а также своими бесплатными утилитами, выпустила бесплатное руководство "Veeam Unofficial VMware VCP-DCV 2020 Study Guide", которое позволит вам подготовиться к главному экзамену на сертифицированного специалиста VMware Certified Professional Datacenter Virtualization (VCP-DCV 2020).
Руководство от Veeam на 133 (!) страницах позволит вам качественно подготовиться к сдаче этого экзамена и с помощью практических заданий отточить все основные операции по администрированию виртуальной инфраструктуры VMware vSphere 7.
Основные разделы документа:
VMware vSphere architectures & technologies
VMware product and solutions
Installing, configuring and setting up a VMware vSphere solution
Performance-tuning and optimizing a VMware vSphere solution
Administrative and operational tasks in a VMware vSphere solution
Очень полезный документ для тех, кто готовится к экзамену, а главное - бесплатный. На страницах есть ссылки на документацию VMware по данной теме, а также QR-коды, чтобы легко переходить с распечатанного руководства на электронную версию соответствующего раздела документации.
Скачать Veeam Unofficial VMware VCP-DCV 2020 Study Guide можно по этой ссылке.
Несмотря на то, что компания VMware представила версию средства для создания отказоустойчивых хранилищ vSAN 6.5 еще в 2016 году, многие крупные компании продолжают ей пользоваться. Между тем, надо понимать, что скоро браузеры отключат поддержку Flash, и все консоли на базе этой технологии (а именно на ней работает старый vSphere Web Client) просто прекратят работать (в Chrome это запланировано на декабрь этого года).
Чтобы вы могли и дальше использовать vSAN 6.5, нужно накатить патч vSAN 6.6.1 Patch 05 (вышел еще 30 июля), в котором добавлена поддержка технологии HTML5, поддерживающейся всеми современными браузерами. О возможностях vSAN 6.6.1 мы писали вот тут.
В новом апдейте vSAN 6.6.1 на базе мажорной версии 6.5 есть следующие нововведения:
Отчеты о производительности вы можете найти в Cluster > вкладка Monitor > секция vSAN > Performance
Добавлена панель общей информации в разделе Virtual object, показывающая размещение и доступность объектов в кластере. Также можно фильтровать список по статусу и типу объектов.
В разделе Virtual Objects/ View data placement есть чекбокс "Group components by host placement", который дает возможность увидеть состояние компонентов данных и быстрее обнаружить потенциальные проблемы на хостах ESXi.
Также из блога VMware мы утянули вот такое видео с обзором интерфейса HTML5 для vSAN 6.6.1:
На днях компания VMware обновила пару продуктов линейки серверной платформы, выпустив обновления компонентов vSphere 6.7 Update 3:
Давайте посмотрим, что нового появилось в vCenter и ESXi:
vCenter 6.7 Update 3j
Поддержка SMTP-аутентификации в виртуальном модуле vCenter Server Appliance для отсылки алертов и алармов по почте в защищенном режиме. Можно также использовать и анонимный режим.
Еженедельное оповещение о приближении устаревания сертификатов для служб vCenter Single Sign-On Security Token Service (STS). Напоминалки начинаются за 90 дней и появляются каждую неделю.
Через Managed Object Browser можно сделать hard stop виртуальной машины на случай, если это невозможно сделать из гостевой ОС. Формат вызова такой: https://10.100.200.300/mob/?moid=vm-518&method=terminate
Обновления базовой операционной системы Photon OS.
В основном, этот релиз содержит исправления ошибок, среди которых есть и критические ошибки, приводившие к падению хоста ESXi. Полный список фиксов доступен в тут.
VMware Tools 11.1.5
В основном, этот релиз содержит исправления ошибок, полный список фиксов доступен тут. Также обновился openssl до версии 1.0.2v. Пакеты VMware Tools для Windows подписаны сертификатами Microsoft на базе SHA-2.
Небольшое обновление ESXi 6.5 Update 3 PO5
В основном, этот релиз содержит исправления ошибок, полный список фиксов доступен тут.
Скачать VMware vSphere 6.7 Update 3 и обновленный vCenter 6.7 Update 3j можно по этой ссылке.
Напомним, что Intel Optane DC persistent memory (DCPMM) - эта память не такая быстрая как DRAM и имеет бОльшие задержки, но они все равно измеряются наносекундами. При этом данная память позволяет иметь ее большой объем на сервере, что существенно повышает плотность ВМ на одном хосте.
Модули DCPMM изготавливаются под разъем DDR4 и доступны планками по 128, 256 и 512 ГБ. В одной системе может быть до 6 ТБ памяти DCPMM. Платформа VMware vSphere 6.7 EP10 и более поздние версии поддерживают память Intel Optane persistent memory 100 series (она же Intel Optane PMem) со вторым поколением процессоров Intel Xeon Scalable в режимах App Direct и Memory.
В указанном документе рассматривается производительность данной памяти в новом режиме Balanced Profile для конфигурации BIOS, который впервые появился в процессорах Intel этой серии в целях повышения производительности. За счет данного режима производительность памяти увеличилась в 1.75 раза, как показано на картинке по результатам тестов:
Четыре года назад мы публиковали табличку, которая показывает соответствие билдов различных продуктов VMware их официальным версиям (а до этого мы публиковали табличку 6 лет назад).
С тех пор много чего изменилось, в том числе добавились новые продукты, поэтому ниже таблица с нужными ссылками для соответствующих продуктов и датами релизов:
Продукт
Статья базы знаний VMware KB
VMware Converter Standalone (продукт не обновляется)
Сдать этот экзамен вы можете онлайн (но под наблюдением) через сайт Pearson VUE.
Вторая важная новость - это то, что теперь сертификации Data Centre Virtualisation certification (VCP-DCV 2020) и Network Virtualization 2020 (VCP-NV 2020) не требуют сдачи теста Foundations Exam, а лишь прохождения соответствующих треку сертификации курсов.
Для того, чтобы не сдавать этот экзамен просто выберите пункт no VCP certifications (Foundations exam not required) в разделе Certification Path:
Наверняка не все из вас видели новость компании VMware о том, что теперь релизы новых бета-версий платформы VMware vSphere будут происходить в рамках программы vSphere Continuous Beta.
Что это значит для администраторов?
Переход на Continuous Beta означает, что обновленные билды с новыми фичами vSphere будут выкладываться и обновляться на VMware Communities по ссылке выше постоянно, без длинных промежутков между ними.
Новая функциональность в этих билдах не будет привязана к конкретной версии vSphere, а администраторы смогут дать фидбэк по различным возможностям продукта. На базе пользовательского фидбэка будет уже формироваться список фич, которые будут включены в тот или иной релиз платформы.
Кстати, после скачивания и того, как вы зарегистрируетесь в бета-программе, вас "в нагрузку" попросят выполнить определенные задачи по тестированию неких блоков функциональности. Также вам будет предоставлен доступ в Beta Community, где вы сможете обсудить свой опыт тестирования платформы и внести предложения. Там же можно напрямую общаться как с техническими специалистами VMware, так и с командой технического маркетинга, которая отвечает в том числе за включение фич в релиз.
Ну и самое главное - новая бета-версия VMware vSphere уже ждет вас на портале программы. Переходите по этой ссылке, чтобы зарегистрироваться в VMware vSphere Continuous Beta Program.
Возможно, некоторые администраторы VMware vSphere попадали в ситуацию, когда один из датасторов в виртуальной инфраструктуре оказывался не привязанным ни к какому хосту ESXi, но при этом у него также была неактивна опция Delete Datastore из контекстного меню:
Такой зомби-датастор можно удалить только из базы данных vCenter Server Appliance (vCSA), поэтому вы полностью должны быть уверены в том, что он не используется никаким из хостов, а также в том, что он не презентует никакое физическое устройство в вашей инфраструктуре.
Первое что вам надо сделать - это включить доступ к vCSA по SSH (картинки - отсюда):
Далее нужно зайти по SSH на vCSA, запустить там шелл командой shell и далее запустить утилиту psql для работы с базой данных следующей командой:
После этого нужно найти id датастора следующей командой:
VCDB=# SELECT id FROM vpx_entity WHERE name = 'MyStubbornDatastore';
Когда вы нашли id, нужно удалить упоминание об этом датасторе из таблиц базы данных vCSA следующими командами:
DELETE FROM vpx_ds_assignment WHERE ds_id=3089;
DELETE FROM vpx_datastore WHERE id=3089;
DELETE FROM vpx_vm_ds_space WHERE ds_id=3089;
При выполнении второй операции вы получите следующую ошибку:
ERROR: update or delete on table "vpx_datastore" violates foreign key constraing "fk_vpxspace"
DETAIL: Key (id)=(3089) is still referenced from table "vpx_vm_ds_space".
Не обращайте на нее внимания и выполняйте третью. Затем нужно перезагрузить vCSA и снова выполнить второй DELETE, который в этот раз должен завершиться успешно. После этого датастор пропадет из списка в vSphere Client.
Помните, что выполняя данную операцию, вы должны понимать, что именно делаете:)
На блогах VMware вышла отличная статья про безопасность виртуальных машин и виртуальной инфраструктуры VMware vSphere в целом, расскажем ниже ее основные моменты.
Как известно, одним из действенных способов атак на виртуальную инфраструктуру vSphere является проведение злоумышленником вредоносных действий из виртуальной машины, которая потом уничтожается, часто не оставляя следов и записанных действий. Еще один интересный способ со спецификой виртуализации - украсть виртуальную машину (например, контроллер домена) и ковыряться в ней уже в своей песочнице, чтобы вытащить нужную информацию.
На этом уровне важной составляющей является пакет VMware Tools, имеющий широкие возможности доступа к виртуальной машине - ОС и приложениям. Управление поведением тулзов происходит с помощью вот этих утилит:
Само собой приведенные ниже рекомендации - это руководство для параноиков (но, как говорит Эндрю Гроув - выживают только параноики), потому что безопасность, как вы знаете - это всегда компромисс между удобством и маниакально-призрачным ощущением защищенности.
И вот тут рекомендуется принять во внимание следующие факторы на уровне VMware Tools:
1. Отключить синхронизацию времени с хостом VMware ESXi
Время - очень важная категория в контексте безопасности. Оно важно для логов, для синхронизации событий аутентификации и прочего. По-хорошему, гостевая ОС должна получать время от NTP-сервера, а не от ESXi, который может быть скомпрометирован. Если вы сомневаетесь, что у вас настроено иначе, нужно принудительно отключить синхронизацию времени с хостом. Делается это следующей командой:
VMwareToolboxCmd.exe timesync disable
2. Отключить автообновление VMware Tools
Если у вас в компании принято, что рабочий процесс обновления системных компонентов должен быть унифицирован и контролироваться из одной точки, то можно отключить автоапдейт VMware Tools. Делается это так:
VMwareToolboxCmd.exe config set autoupgrade allow-upgrade false
VMwareToolboxCmd.exe config set autoupgrade allow-add-feature false
VMwareToolboxCmd.exe config set autoupgrade allow-remove-feature false
3. Отключить возможность кастомизации ОС при клонировании
Такая опция позволяет изменять параметры виртуальной машины и гостевой системы, что может быть выгодно злоумышленнику. Отключить кастомизацию ВМ можно следующей командой:
VMwareToolboxCmd.exe config set deployPkg enable-customization false
4. Контроль над информацией, предоставляемой через Appinfo
Об интерфейсе Appinfo мы писали вот тут (он же Application Discovery). Он позволяет, например, собирать информацию о запущенных приложениях внутри гостевой системы (по умолчанию сбор идет каждые 30 минут, это настраивается).
Отключить Appinfo в виртуальной машине можно следующей командой VMware Tools:
VMwareToolboxCmd.exe config set appinfo disabled true
5. Отключить Guest Operations (оно же Invoke-VMScript)
Командлет Invoke-VMScript - это мощный механизм для разработчиков, позволяющий работать с гостевой системой виртуальной машины со стороны механизма сценариев PowerCLI. Очевидно, что этот интерфейс расширяет поверхность потенциальной атаки, и если вы им не пользуетесь, то его лучше отключить. Делается это следующей командой:
VMwareToolboxCmd.exe config set guestoperations disabled true
6. Отключение ненужных компонентов
Это базовое правило - чем меньше компонентов VMware Tools у вас установлено, тем меньше вероятность, что через какой-то из них произойдет атака. Например, не всем пользователям и администраторам нужны такие возможности, как Service Discovery, AppDefense и Shared Folders. Но здесь, очевидно, нужно соблюдать разумный баланс - не надо отключать что-то нужное, о чем вы потом будете думать: "почему оно не работает?".
Подробнее об отключении компонентов VMware Tools при развертывании через утилиту командной строки написано тут.
Некоторые функции vCloud Director (VCD) по работе с виртуальными машинами по-прежнему недоступны через стандартные командлеты PowerCLI, поэтому к ним необходимо обращаться через VCD API.
Jon Waite в своем блоге опубликовал PowerCLI-сценарий, с помощью которого можно обратиться к VCD API и увеличить размер загрузочного диска ВМ. Надо сказать, что при подобного рода манипуляциях (как увеличение, так и уменьшение диска) всегда есть риск потери данных, поэтому обязательно сделайте резервную копию.
Стандартное определение функции - на входе объект виртуальная машина и новый желаемый размер первого (загрузочного) диска в МБ.
7-9
Одна команда, разделенная на 3 строчки. Вызов VCD API для определения поддерживаемых версий API, чтобы не хардкодить конкретную версию в скрипте.
10-12
Обрабатывает результат прошлой строчки, определяет последнюю актуальную версию VCD API и сохраняет $APIVersion для использования позднее.
14
Определяет SessionId для текущей сессии PowerCLI (Connect-CIServer), чтобы использовать API-запросы на строчках 17 и 27.
15
Получает хэш $Headers для отправки API-запросов (переменные SessionId и APIVersion были получены ранее).
16
Определяет API URI через поддерживаемый VM HTTP reference.
17
Получает представление XML секций virtualHardwareSection/disks определенной ВМ.
19-20
Находит первый диск, привязанный к ВМ (ResourceType 17 = Hard Disk)
22-23
Обновляет размер диска ВМ на базе входного параметра емкости у функции. На самом деле у VCD достаточно обновить capacity, а VirtualQuantity обновляем для консистентности (в байтах).
24
Добавляем дополнительное значение к $Header, чтобы обозначить Content-Type, который мы отправляем обратно к API.
26-34
Попытки обновить API измененным XML, включая новый размер диска и возвращаем ошибку с описанием, если операция прошла неудачно.
После выполнения сценария нужно будет, само собой, расширить соответствующий раздел гостевой системы. Современные версии Windows и Linux могут раскатывать существующий раздел на весь размер физического устройства даже без перезагрузки машины.
Пример использования сценария:
PS /> $VM = Get-CIVM -Name 'TestVM01'
PS /> $VM | Update-CIVMBootDisk -NewSizeMB 2048
Disk resize for VM TestVM01 submitted successfully.
При описании новых возможностей VMware vSphere 7 мы рассказывали о функциях платформы, появившихся в результате приобретения VMware компании Bitfusion. Эти возможности позволяют оптимизировать использование графических процессоров GPU в пуле по сети, когда vGPU может быть частично расшарен между несколькими ВМ. Это может применяться для рабочих нагрузок задач AI/ML (например, для приложений, использующих PyTorch и/или TensorFlow).
Все это позволяет организовать вычисления таким образом, что хосты ESXi с аппаратными модулями GPU выполняют виртуальные машины, а их ВМ-компаньоны на обычных серверах ESXi исполняют непосредственно приложения. При этом CUDA-инструкции от клиентских ВМ передаются серверным по сети.
Технология эта называлась FlexDirect, теперь это продукт vSphere Bitfusion:
На днях это продукт стал доступен для загрузки и использования в онпремизных инфраструктурах.
Возможность динамической привязки GPU к любой машине в датацентре, по аналогии с тем, как вы привязываете к ней хранилище.
Возможность использования ресурсов GPU как одной машине, так и разделения его между несколькими. При этом администратор может выбрать, какой объем Shares выделить каждой из машин, то есть можно приоритизировать использование ресурсов GPU между потребителями.
Возможность предоставления доступа как по TCP/IP, так и через интерфейс RDMA, который может быть организован как подключение Infiniband или RoCE (RDMA over Converged Ethernet). О результатах тестирования такого сетевого взаимодействия вы можете почитать тут.
Передача инструкций к серверным машинам и обратно на уровне CUDA-вызовов. То есть это решение не про передачу содержимого экрана как VDI, а про высокопроизводительные вычисления.
Прозрачная интеграция - с точки зрения приложений менять в инфраструктуре ничего не нужно.
Для управления инфраструктурой доставки ресурсов GPU используется продукт vSphere Bitfusion Manager, который и позволяет гибко распределять ресурсы между потребителями. Раньше он выглядел так:
Теперь же он интегрирован в vSphere Client как плагин:
Архитектура Bitfusion позволяет разделить виртуальную инфраструктуру VMware vSphere на ярусы: кластер GPU, обсчитывающий данные, и кластер исполнения приложений пользователей, которые вводят данные в них и запускают расчеты. Это дает гибкость в обслуживании, управлении и масштабировании.
С точки зрения лицензирования, решение vSphere Bitfusion доступно как аддон для издания vSphere Enterprise Plus и лицензируется точно так же - по CPU. Для других изданий vSphere, увы, этот продукт недоступен.
Многие администраторы VMware vSphere знают, что иногда в виртуальной инфраструктуре может возникнуть ситуация APD (All Paths Down). Это состояние, когда хост-сервер ESXi не может получить доступа к устройству ни по одному из путей, а также устройство не дает кодов ответа на SCSI-команды. При этом хост не знает, в течение какого времени будет сохраняться такая ситуация.
Типичный пример - отказ FC-коммутаторов в фабрике или выход из строя устройства хранения. В этом случае хост ESXi будет периодически пытаться обратиться к устройству (команды чтения параметров диска) через демон hostd и восстановить пути. В этом случае демон hostd будет постоянно блокироваться, что будет негативно влиять на производительность. Этот статус считается временным, так как устройство хранения или фабрика могут снова начать работать, и работа с устройством возобновится.
При настройке механизма VMware vSphere HA на уровне кластера у вас есть следующие опции реагирования на такую ситуацию:
Disable - ничего не делать с виртуальными машинами
Issue Event - ничего не делать, но сгенерировать событие
Power Off / Restart – Conservative
Power Off / Restart – Aggressive
Последние два варианта - Conservative и Aggressive - не очень ясны. Отличие между ними заключается в том, что в консервативном (Conservative) сценарии механизм VMCP (VM Component Protection) сработает только тогда (выключит ВМ), когда убедится, что виртуальные машины могут быть перезапущены на других хостах кластера. В этом случае ESXi убеждается, что связь с другими хостами есть и у них есть доступ к хранилищу ВМ.
В случае политики Aggressive виртуальные машины будут выключены в любом случае, даже если хост не может убедиться, что они могут быть перезапущены на других хостах кластера. Это может произойти в случае полного распада сети, когда хосты ESXi не видят друг друга по сетям сервисной консоли и сети хранения данных. Но если ESXi точно знает, что машины не перезапустятся на других хостах, то и в случае Aggressive он не будет выключать ВМ. То есть выбор всегда делается в пользу наибольшей доступности виртуальных машин.
Иногда, конечно, лучше убить процесс виртуальной машины, если вы попадаете в ситуацию неопределенности в кластере. Ведь лучше выключить машину, чем иметь от нее подтверждения записи на диск, хотя фактически этой записи не происходит. Если вы хотите минимизировать вероятность поддержания таких ВМ в рабочем состоянии для приложений, когда их хранилище отвалилось полностью, вы можете добавить вот такую настройку vSphere HA для всего кластера:
Не все администраторы знают, что при апгрейде VMware ESXi на более новую мажорную версию есть возможность сохранить предыдущую конфигурацию гипервизора для возможности отката в случае неудачного обновления. Такая возможность, например, есть при апгрейде ESXi 6.5 на версию 6.7.
Для этого нужно во время установки выбрать пункт "Upgrade ESXi, preserver VMFS datastore". Под датастором тут имеется в виду, что на нем сохранится предыдущая установка ESXi:
Кстати, как видно из скриншота, можно сделать и свежую установку ESXi с возможностью отката к предыдущей версии.
Итак, вы сделали апгрейд ESXi, но что-то пошло не так. Например, ваше железо больше не поддерживается (к примеру, CPU), и вам надо сделать откат к прошлой версии ESXi. Для этого во время загрузки вам нужно нажать комбинацию клавиш Shift + <R>:
После этого можно будет выбрать предыдущую версию ESXi и заменить ей новую установку, полностью откатившись к прошлому гипервизору и его настройкам:
Также можно делать бэкап и восстановление конфигурации VMware ESXi - об этом рассказано в KB 2042141.
RSS
